While the `RetryPolicy` has a `MaxTotalDelayRetryPolicy`, the retry
`loop` would only check this configured delay once the operation future
actually returns a value. However, without client-side timeouts, we're
not super sure the operation is actually guaranteed to return anything
(even an error, IIUC).

So here, we enable some coarse client-side default timeouts to ensure
the polled futures eventualy return either the response *or* an error we
can handle via our retry logic.

We here make use of `reqwest`'s `retry` functionlity that was introduced
with its recent v0.12.23 release. As we can't fully replace the old
'application-level' behavior just yet, we configure it to only apply for
error that arent INTERNAL_SERVER_ERROR, which is the status VSS uses to
send error responses.

We set some default values here, but note that these can always can be
overridden by the user when using the `from_client` constructor.